The present invention relates generally to interface devices for allowing humans to interface with computer systems and provide force feedback to the user, and more particularly to the control of force sensations output by force feedback interface devices.
Using an interface device, a user can interact with an environment displayed by a computer system to perform functions and tasks on the computer, such as playing a game, experiencing a simulation or virtual reality environment, using a computer aided design system, operating a graphical user interface (GUI), or otherwise influencing events or images depicted on the screen. Common human-computer interface devices used for such interaction include a joystick, mouse, trackball, steering wheel, stylus, tablet, pressure-sensitive ball, or the like, that is connected to the computer system controlling the displayed environment. Typically, the computer updates the environment in response to the user""s manipulation of a user-manipulatable physical object (xe2x80x9cmanipulandumxe2x80x9d) such as a joystick handle or mouse, and provides visual and audio feedback to the user utilizing the display screen and audio speakers. The computer senses the user""s manipulation of the user manipulandum through sensors provided on the interface device that send locative signals to the computer.
In some interface devices, haptic feedback is also provided to the user, also known as xe2x80x9cforce feedback.xe2x80x9d These types of interface devices can provide physical sensations which are felt by the user manipulating the physical object of the interface device. For example, the Force-FX joystick controller from CH Products, Inc. or the Wingman Force joystick from Logitech may be connected to a computer and provides forces to a user of the controller. Other systems might use a force feedback mouse controller. One or more motors or other actuators are used in the device and are connected to the controlling computer system. The computer system controls forces on the force feedback device in conjunction and coordinated with displayed events and interactions on the host by sending control signals or commands to the force feedback device and the actuators. The computer system can thus convey physical force sensations to the user in conjunction with other supplied feedback as the user is grasping or contacting the manipulandum of the interface device. For example, when the user moves the manipulandum and causes a displayed cursor to interact with a different displayed graphical object, the computer can issue a command that causes the actuator to output a force on the manipulandum, conveying a feel sensation to the user.
In preferred embodiments, the application program running on the host interacts with a library available on the host which is dedicated to the control and implementation of force feedback using the interface device. Such a library can be, for example, an xe2x80x9cApplication Program Interfacexe2x80x9d (API) in the Windows operating system, which are commonly used to provide functionality to an application program; or the equivalent for other systems such as other operating systems or game consoles. Examples of API""s include I-Force(copyright) and the FeelIt(trademark) API""s available from Immersion Corp. of San Jose, Calif. These API""s run on the host computer beneath the application program level and respond to high level calls to implement force feedback for force feedback devices and related functions. The application program need only specify particular force sensations by name and parameters which characterize the force sensations using the API""s.
A problem with the prior art development and control of force feedback sensations in software is that the programmer of force feedback application programs must provide control over many different types of individual force sensations (xe2x80x9cforce effectsxe2x80x9d) and must coordinate this control at a low level. For example, a generalized control process 2 in the prior art is shown in FIG. 1. In an initialization step 4, the application program sends any force effects it desires to be applied to the API, with any basic effect parameters. In some embodiments, these basic effect parameters can be read by the API from a standardized file, such as an xe2x80x9cIFRxe2x80x9d file, that specifies the force effects and their parameters and which the API interprets to load force effect data on the device.
The application program then processes steps in the running of the application program. One of these steps is step 6, where the application checks the xe2x80x9cworld statusxe2x80x9d of the program with respect to force feedback. The world status changes based on time, user input, input from other sources, random events, and other criteria. For example, a user controlled graphical object or entity may have been moved from one region into another in a graphical environment, and the world status reflects this movement. In step 8, the application program determines the contributions for each desired force effect that is to be output based on the current world state. Thus, the application program must determine which individual force effects should be played, as well as determine the particular parameters for these force effects based on the current world status, such as duration, magnitude, direction, frequency, etc. In step 9, the application program modifies and commands force effects so that the force effects are output to the force feedback device. This is accomplished by sending force effect commands with the desired parameters and changes. The API and lower-level drivers receive the force effect commands and translate those commands into data which the force feedback device can interpret. The force feedback device outputs force sensations in accordance with the commands. The process on the host computer then returns to step 6 to get the latest world status. This process loop should run on the order of 30 times per second to provide adequate force feedback.
In the example above, the application program must perform many detailed individual force-feedback related tasks that the designer of the application program must work out and implement. The degree of attention required to implement such low-level handling of force effects takes away from other aspects of the design of the application program, and/or causes the designer to cut back on the implementation of the force feedback in the program, leading to less immersive and compelling force sensations in application programs.
The present invention is directed to commanding force effects using suites or categories to allow an application program higher level control over force sensations output by a force feedback interface device.
More particularly, a method of the present invention for commanding force effects using force suites is described. The force effects are commanded by an application program running on a host computer, and the host computer is coupled to a force feedback interface device that outputs force sensations to a user. An application program associates a force suite with one or more individual force effects and the suite association is provided to a library available to the application program on the host computer, such as an Application Programming Interface (API). A set of rules is also preferably provided to the library, the rules determining how to apply the force effects in the suite based on a status of the application program. The application program commands at least one force effect in the suite and reports the status of the application program to the library, where the library applies the rules based on the reported status to cause a force sensation based on the commanded force effect to be output by the force feedback interface device.
For example, the status of the application program can include calling the suite to be loaded to memory on the force feedback interface device, where the library determines whether any of the force effects in the loaded suite are to be output to the user. Or, the status of the application program includes a location of a user-controlled entity in the application program, such as a cursor or a character in a game, which allows the library to determine suites and effects by applying the location to the rules.
The suites and the force effects within the suites can also be provided with priorities to help the library determine which suites and/or force effects should be output if there is a conflict or a limitation in the force feedback system that requires that some force effects not be loaded or played.
The present invention advantageously provides an application program with force effect suites in which to organize force effects for more simplified and effective command of force sensations. The application program need only report a minimum of information to a library, such as a world status of the application, and the library can determine which effects should be loaded and/or output based on the world status. This allows an application program developer to concentrate on the force design itself to a greater extent without spending resources on lower level management of force effects by the application program. Priority levels assigned to suites and force effects also allow the library to handle conflicts in force effects and limitations in device hardware without direct supervision from the application program.
These and other advantages of the present invention will become apparent to those skilled in the art upon a reading of the following specification of the invention and a study of the several figures of the drawing.